fix: update dependency io.netty:netty-transport-native-epoll to v4.2.13.final [security]#805
Conversation
…13.final [security]
trusted-contributions-gcf
Bot
added
the
kokoro:force-run
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the netty-transport-native-epoll dependency to version 4.2.13.Final. The review feedback identifies a potential risk of version mismatch and runtime errors when updating Netty modules individually, suggesting that all Netty dependencies should be updated together or managed through a BOM to ensure consistency.
| <groupId>io.netty</groupId> | ||
| <artifactId>netty-transport-native-epoll</artifactId> | ||
| <version>4.2.12.Final</version> | ||
| <version>4.2.13.Final</version> |
There was a problem hiding this comment.
Updating only the netty-transport-native-epoll version while other Netty dependencies are likely managed by the grpc-bom (line 40) can lead to version mismatches in the classpath. Netty requires all its modules (such as netty-common, netty-transport, and netty-buffer) to have the exact same version to avoid runtime errors like NoSuchMethodError. When updating dependencies, especially those not managed by a BOM, verify the version's release date to ensure it is current and compatible with other libraries. To ensure consistency, it is recommended to also update the other Netty dependencies to 4.2.13.Final, or better yet, add the netty-bom to the dependencyManagement section with the desired version.
References
- When updating dependencies, especially those not managed by a BOM, verify the version's release date to ensure it is current and compatible with other libraries.
1 participant
This PR contains the following updates:
4.2.12.Final→4.2.13.FinalNetty epoll transport denial of service via RST on half-closed TCP connection
CVE-2026-42577 / GHSA-rwm7-x88c-3g2p
More information
Details
Summary
Netty's epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread.
Affected versions
All versions of 4.2.x
netty-transport-native-epollup to and including 4.2.12.FinalFixed in
4.2.13.Final (fix merged into the
4.2branch via #16689; release not yet cut as of 2026-04-25).Severity
Medium — Denial of Service (resource exhaustion / CPU spin)
CWE: CWE-772: Missing Release of Resource after Effective Lifetime
Description
When a TCP connection using Netty's epoll transport has
ALLOW_HALF_CLOSUREenabled (or is in a half-closed state via the HTTP codec), and the remote peer:SO_LINGER=0)the server-side channel is never closed. This happens because:
epollOutReady()is a no-op when there is no pending flush.epollInReady()short-circuits viashouldBreakEpollInReady()because input is already marked as shutdown.EPOLLERR/EPOLLHUPerror condition is therefore never processed, andchannelInactiveis never fired.Depending on the Netty version and configuration, this results in:
clearEpollIn0()is not called during theChannelInputShutdownReadCompleteevent,epoll_waitreturns immediately on every iteration for the affected fd, causing 100% CPU utilization on the event loop thread and starving all other connections multiplexed on it.Mitigation
4.2branch at commit0ec3d97).Resources
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.